Skip to content
This repository has been archived by the owner on Jun 5, 2024. It is now read-only.

Add the energy range based on the total energy deposit in the sensitive volume #76

Merged
merged 9 commits into from
Feb 7, 2024

Conversation

MasatoshiKobayashi
Copy link
Contributor

Two new options are added: Max energy and Min energy, so that we can reduce the amount of events to be simulated before WFSim.
The "energy" used in this selection is the total amount of deposited energy in the sensitive volume.
The selection is made with function "apply_energy_selection" and "calc_tot_e_dep" -- note that the calculation of total energy will have performed only when we give either Max or Min energy threshold.

@PavelKavrigin
Copy link
Contributor

@MasatoshiKobayashi @ramirezdiego - I ran some tests with these epix/wfsim updates, including a test with mc_chain (branch "lower_test"), simulating "InnerCryostat_Co60" with these branches. I've seen two issues so far:

  • if we end up with zero events after applying the energy selection, the simulation will crash,
    either here:
    strax_interface.py#L823
    or here:
    common.py#L211
    for obvious reasons - the instructions are empty so we don't have these fields. We need to find a proper way to handle these exceptions.

  • Since the selection is applied in epix, we still have an issue with large G4 files. For instance, in Co60 simulations we still cannot use more than 5E3 primaries per simulation or so, because the file size is already around 40 [Mb] with 5E3 primaries. It's a problem because (a) epix does not handle large G4 files very well right now since it does not read it in chunks; (b) we will still generate huge G4 output at the temporary directories at OSG. If we need 1E8 primaries for this single Co60 simulation, it's already close to 1 [Tb] of G4 output in total + we will need to run it with 2E4 jobs in parallel. We need to think whether we can apply some reasonable/safe pre-selection at G4 level.

@MasatoshiKobayashi
Copy link
Contributor Author

Hi @PavelKavrigin , thank you for your check!
I am not so much familiar with the WFSim, but if possible the simplest way is to finish the epix if the selection is empty.

Regarding the G4sim, I'll have a look. I am apply pre-pre G4 level section, for example, if there is already the large E-dep in the TPC don't save the event.

@MasatoshiKobayashi
Copy link
Contributor Author

@PavelKavrigin
If we just remove the step with position R>68cm or Z<-170cm, the size of G4 file could be reduced down to 1/3. Is it still possible to run the epix with this? Or do we have to keep all steps to run?

RZ_aft_sel RZ_full

@PavelKavrigin
Copy link
Contributor

@MasatoshiKobayashi - I think it's OK if we select all steps within the TPC at the G4 stage. Energy selection is more tricky since we will need to sum up all energy depositions within the TPC, not within the whole LXe, and we also need to take into account the time of the interactions - if we do not postpone radioactive decays, for instance, we might run into problems if we simply reject all events with a total energy deposition in the TPC larger than a certain threshold.

@MasatoshiKobayashi
Copy link
Contributor Author

MasatoshiKobayashi commented Jan 16, 2024

@PavelKavrigin
I guess the simplest solution for the empty instruction is inserting something like:

if len(self.instructions_epix)==0:
  print("the instruction is empty")
  sys.exit(0)

around here? https://github.com/XENONnT/WFSim/blob/617532f7498af23e1bf808c8fd47df1477f82cf2/wfsim/strax_interface.py#L801

@MasatoshiKobayashi
Copy link
Contributor Author

MasatoshiKobayashi commented Jan 24, 2024

@PavelKavrigin
I pushed some lines so that to return the empty instructions if no events are left after the selection.
Also, wfsim side was updated to abort without crashing with empty epix instruction:
XENONnT/WFSim@473b314

* Fix cut_by_eventid again

* Fix cut_by_eventid again (#80)

Co-authored-by: Pavel Kavrigin <[email protected]>

---------

Co-authored-by: Pavel Kavrigin <[email protected]>
@ramirezdiego ramirezdiego merged commit d4b73a7 into master Feb 7, 2024
1 check passed
@ramirezdiego ramirezdiego deleted the lower_devel branch February 7, 2024 10:25
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants